Years ago, in the infancy of the computer age, it was not uncommon for a single programmer to write the entirety of a piece of software tailored to a particular task and even to a particular machine. Eventually, libraries of reusable pieces of code were developed so that already written and debugged code could be used again and again, thereby achieving efficiencies in software development.
Object-oriented programming languages have become very popular. An “object” in an object-oriented programming language is an encapsulated module of code and related data that is externally accessible through interfaces accessing well-defined and controlled connection points, known as the object's methods and properties. A collection of objects can be created to perform the functions desired in a computer application.
Component Object Model (COM) is a platform for software componentry used to enable interprocess communication and dynamic object creation in any programming language that supports the technology. The term COM is often used in the software development world as an umbrella term that encompasses the OLE, OLE Automation, Active®, COM+ and DCOM technologies. COM provides a language-neutral way of implementing objects so an object can be used in an environment different from the one in which it was created.
A recent development in the computer world is the creation of managed code environments. Managed code is computer program code that executes under the management of a virtual machine. In contrast, native (unmanaged) code is executed directly by a computer's central processing unit (CPU). The programming language used to create the program determines whether it will run as managed code or as unmanaged code. Virtual machine environments can support many types of programming languages, including both strongly-typed, early bound languages and loosely-typed languages.
When a program written in a strongly-typed language calls an object using an interface written in a loosely-typed manner, incompatibilities surface. In a loosely-typed, late-bound language the compiler does not do type-checking. Type incompatibilities are not detected until the program executes. If a type incompatibility is detected when a program is running, an exception is thrown. In contrast, a managed code language may be a strongly-typed and early-bound language, meaning that the compiler does type-checking at compile time. A program written in a strongly-typed programming language that makes a call to an object using an interface written in a loosely-typed manner will lose the advantages associated with compile-time type-checking.
A loosely-typed object-oriented programming language may make extensive use of optional parameters, variant types, and parameterized properties. In contrast, a strongly-typed language may not support optional parameters, named parameters, or parameterized properties. Sometimes variant types are handled awkwardly in a strongly-typed language. When a developer working in a strongly-typed language calls an object in a shared library using an interface written in a loosely-typed manner, these language incompatibilities can result in increased work for the developer, awkward program code, loss of desired language features and an increase in programming errors.